Content delivery networks (CDNs) have greatly improved the way content is transferred across data networks such as the Internet. A CDN accelerates the delivery of content by reducing the distance that content travels in order to reach a destination. To do so, the CDN strategically locates surrogate origin servers, also referred to as caching servers or edge servers, at various points-of-presence (POPs) that are geographically proximate to large numbers of content consumers and the CDN utilizes a traffic management system to route requests for content hosted by the CDN to the edge server that can optimally deliver the requested content to the content consumer. Determination of the optimal edge server may be based on geographic proximity to the content consumer as well as other factors such as load, capacity, and responsiveness of the edge servers. The optimal edge server delivers the requested content to the content consumer in a manner that is more efficient than when origin servers of the content publisher deliver the requested content. For example, a CDN may locate edge servers in Los Angeles, Dallas, and New York. These edge servers may cache content that is published by a particular content publisher with an origin server in Miami. When a content consumer in San Francisco submits a request for the published content, the CDN will deliver the content from the Los Angeles edge server on behalf of the content publisher as opposed to the much greater distance that would be required when delivering the content from the origin server in Miami. In this manner, the CDN reduces the latency, jitter, and amount of buffering that is experienced by the content consumer. The CDN also allows the content publisher to offload infrastructure, configuration, and maintenance costs while still having the ability to rapidly scale resources as needed. Content publishers can therefore devote more time to the creation of content and less time to the creation of an infrastructure that delivers the created content to the content consumers.
As a result of these and other benefits, many different CDNs are in operation today. Edgecast, Akamai, Limelight, and CDNetworks are some examples of operating CDNs that are responsible for the delivery of terabytes worth of content. FIG. 1 illustrates a representative infrastructure for some such CDNs. As shown in FIG. 1, the infrastructure includes a distributed set of edge servers 110, traffic management servers 120, and an administrative server 130. The figure also illustrates the interactions that CDN customers including content publishers have with the CDN and interactions that content consumers or end users have with the CDN.
Each edge server of the set of edge servers 110 may represent a single physical machine or a cluster of machines. The cluster of machines may include a server farm for a geographically proximate set of physically separate machines or a set of virtual machines that execute over partitioned sets of resources of one or more physically separate machines. The set of edge servers 110 are distributed across different edge regions of the Internet to facilitate the “last mile” delivery of content. The edge servers run various processes that (1) manage what content is cached, (2) how content is cached, (3) how content is retrieved from the origin server when the content is not present in cache, (4) monitor server capacity (e.g., available processor cycles, available memory, available storage, etc.), (5) monitor network performance (e.g., latency, downed links, etc.), and (6) report statistics on the delivered content. The set of edge servers 110 may provide the monitoring information to the traffic management servers 120 to facilitate the routing of content consumers to the optimal edge servers. The set of edge servers 110 may provide the statistical data to the administrative server 130 where the data is aggregated and processed to produce performance reports for the delivery of the customers' content.
The traffic management servers 120 route content consumers, and more specifically, content consumer issued requests for content to the one or more edge servers. Different CDN implementations utilize different traffic management schemes to achieve such routing to the optimal edge servers. Consequently, the traffic management servers 120 can include different combinations of Doman Name System (DNS) servers, load balancers, and routers performing Anycast or Border Gateway Protocol (BGP) routing. For example, some CDNs utilize the traffic management servers 120 to provide a two-tiered DNS routing scheme, wherein the first DNS tier resolves a DNS request to the CDN region (or POP) that is closest to the requesting content consumer and the second DNS tier resolves the DNS request to the optimal edge server in the closest CDN region. As another example, some CDNs use Anycast routing to identify the optimal edge server.
The administrative server 130 may include a central server of the CDN or a distributed set of interoperating servers that perform the configuration control and reporting functionality of the CDN. Content publishers register with the administrative server 130 in order to access services and functionality of the CDN. Accordingly, content publishers are also referred to as customers of the CDN. Once registered, content publishers can interface with the administrative server 130 to specify a configuration, upload content, and view performance reports. As part of registration and in order to utilize functionality of the CDN, the content publisher may be required to perform local configuration changes. In some instances, the content publisher inserts a CNAME into its domain's authoritative DNS server such that DNS requests for the content publisher's content are resolved by the traffic management servers 120 of the CDN. Other configuration changes by the content publisher may also be necessary to facilitate the offloading of content to the CDN. One such configuration change involves the content publisher prepending a CDN provided Uniform Resource Locator (URL) to the existing URLs for objects hosted by the content publisher origin server. For example, the URL www.pub1.com/object1.jpg will be modified to www.cdn1.com/cid/params/www.pub1.com/object1.jpg. The modified URL causes content consumers to request the object (i.e., object1.jpg) from the CDN domain rather than the content publisher domain. Moreover, the edge servers of the CDN can identify the content that is being requested and the origin server from which to retrieve the requested content should the content not be cached at the edge server.
As noted above, the administrative server 130 is also typically tasked with statistics aggregation and report generation. Specifically, the administrative server 130 aggregates statistics data from each server of the set of edge servers 110 and processes the statistics to produce usage and performance reports. From these reports, the content publisher can better understand the demand for its content, the performance provided by the CDN in delivering the content publisher's content, and the need for capacity reallocation, among other uses.
While many benefits can be achieved from the current CDN model, there are also many shortcomings and restrictions that are inherent with this model. Firstly, the global footprint for any CDN is limited because of infrastructure costs. Instead of deploying edge servers at every edge, state, city, etc., each CDN strategically picks and chooses the regions at which its edge servers are to be deployed. This has led to CDN localization, wherein different CDNs have the infrastructure to best serve different regions. For example, a first CDN may be best for delivering content across the United States and Western Europe, a second CDN may be best for delivering content across South America, and a third CDN may be best for delivering content across Eastern Europe. Another factor precluding the expansion of a CDN is that a particular ISP or network operator can prevent the CDN from establishing a POP or deploying edge servers at certain geographic regions that are controlled by that ISP or network operator. Specifically, the ISP may run its own CDN at the geographic regions under its control and as a result, the ISP will want to avoid any direct competition by preventing another CDN from establishing a POP at those geographic regions. Additionally, the ISP may enter into an exclusive agreement with a first CDN, whereby the first CDN is permitted to establish a POP within a region that is under the control of the ISP while a second CDN is prevented from doing so.
Secondly, CDNs are confronted with a “chicken and egg” problem. A CDN will not expand its infrastructure to a region where there is little to no demand and content publishers and other CDN customers will not utilize the services of a CDN unless there is sufficient infrastructure already in place to accommodate their needs. This has further exacerbated CDN localization. Specifically, larger CDNs do not expand their infrastructure to smaller markets where there is little to no demand, thus allowing for new and smaller CDNs to pop up and service those smaller markets.
Thirdly, CDNs are themselves faced with scalability and capacity issues. This is especially problematic for CDNs that face spikes in demand at specific regions. For example, a majority of demand for a live stream of a local sports team may come from the particular region where the sports team is based. Even though the CDN may have unused capacity and resources at several of its POPs, the POP closest to the particular region can be overwhelmed causing demand to overflow to more remote POPs thereby lowering the overall effectiveness of the CDN. CDNs are hesitant to partner with another CDN because they are in direct competition with one another and partnering with another CDN can lead to customer poaching. Some content publishers have employed the services of two or more CDNs at the same time when a single CDN does not have sufficient capacity at a region to fully service the needs of the content publishers, or to meet commercial interests. This however leads to undesired overhead for the content publishers. Specifically, the content publishers are required to configure and publish their content to the two or more CDNs. Different configurations may be necessary based on the infrastructures of the CDNs. The content publishers are also confronted with different service rates and different performance from each of the CDNs. This further leads to the content publishers receiving disparate and nonconforming reports from each of the CDNs such that it is difficult for the content publishers to ascertain the overall performance and holistic view for the delivery of their content.
Furthermore, the current CDN operational model ties the role of the CDN operator to the role of the CDN service provider. More efficient usage and monetization of the capacity and resources of the CDN operator would be achieved if multiple CDN service providers were allowed access to the capacity and resources of the CDN operator. Specifically, rather than have companies like Akamai, Edgecast, Limelight, etc. act as both a CDN operator and a CDN service provider, it would be more advantageous to allow third party service providers the ability to sell the capacity of the CDN operators. This is particularly the case when Internet Service Providers (ISPs) deploy CDN infrastructure for their own objectives and the ISPs end up with spare capacity within their network, when the ISPs implement CDN functionality within their networks with the express desire to recognize commercial value from the content flowing into their networks from other CDN operators, or when the ISPs consolidate the number of different CDN infrastructures from various CDN service providers that are deployed into their networks. This improved operational model affords advantages to both the CDN operators and the CDN service providers including increased utilization of the CDN operators capacity while allowing the CDN service provider, whoever it may be, to realize the advantages of a CDN without the need to develop the optimized software and without the need to deploy the infrastructure necessary to operate a CDN.
In light of the foregoing, there is a need for a new CDN operational model that improves upon the content delivery capabilities of existing CDNs. There is a need for such a CDN operational model to provide the CDN service provider the ability to scale capacity on-demand without purchasing new infrastructure and without imposing additional overhead on the customer. There is further a need to provide the CDN service provider the ability to expand its presence on-demand beyond the infrastructure and capabilities of a given CDN operator to regions where that CDN operator does not have an established POP. Moreover, there is a need to better utilize the existing capacity of CDN operators to avoid sunk costs from unused capacity.